home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 3 / BBS in a box - Trilogy III.iso / Files / Tele / Internet / UUPC 3.1b25 Folder / Documentation / Protocol notes < prev    next >
Encoding:
Text File  |  1992-01-29  |  10.4 KB  |  217 lines  |  [TEXT/ALFA]
  1. Of protocols and paper bags,
  2. of packetings and pings.
  3.  
  4. UUCP is a general-purpose, computer-to-computer file copying system, on
  5. top of which quite a number of different sorts of applications can be
  6. built.  You can think of UUCP as a three-layer cake, with each layer
  7. handling a different aspect of the file transfer:
  8.  
  9. -  What files should be transferred?
  10. -  How should they be transferred over a communications link?
  11. -  What should be done with them when they arrive?
  12.  
  13. It's possible to have two or more ways of implementing each of these
  14. layers, and to "mix and match" various combinations of these
  15. implementations to suit a particular need.
  16.  
  17. The first layer... deciding which files should be transferred...
  18. is common to all implementations of UUCP.  There is an agreed-upon
  19. process for saying things like:
  20.  
  21. "I want to send you file 'foo', on behalf of a user 'joe' on this
  22.  machine.  OK?"
  23. "Yes, go ahead."
  24. "Here it is........"
  25. "OK, I got it."
  26. "Fine.  User 'sam' on this machine wants you to send me a copy of
  27.  file 'bar', OK?"
  28. "OK, here it is....."
  29. "Got it, thanks.  I'm done."
  30. "I don't have anything to ask you to do at this point."
  31. "Fine.  Goodbye."
  32. "Goodbye."
  33.  
  34. The last layer... deciding what should be done with a file once it
  35. has been transmitted... is also fairly well standardized.  Crudely
  36. speaking, the UUCP system transmits three kinds of files:
  37.  
  38. -  Those which describe a command to be executed by the other
  39.    system... for example, "rmail bob" means "receive mail from somebody
  40.    here, and send it to bob, please".
  41.    
  42. -  Those which describe data which is to be fed into a program
  43.    being run on the other system... for example, a file would be sent
  44.    which contained the message which was to be delivered to "bob".
  45.  
  46. -  Those which contain data being transferred for some other
  47.    purpose... for example, source-file archives which are being
  48.    transferred from a file-server system to a client.
  49.  
  50. Most UUCP transfers involve the first two sorts of files... electronic
  51. mail messages, network-news articles, and the command-files which cause
  52. these messages and articles to be fed to the proper program for delivery
  53. or other processing.
  54.  
  55. As you might guess, there are some real security issues here.  You
  56. (as a system administrator) don't want to permit other people to
  57. execute arbitrary commands on your system, or to transfer files
  58. to or from your system's disks without your permission.  Most
  59. implementations of UUCP place severe restrictions on which programs
  60. can be run via the file-transfer mechanism, and the directories into
  61. which files can be written (or read from).
  62.  
  63. The lowest layer in the "cake"... that of actually transmitting the
  64. data over a communications line... is also fairly standardized.  It has
  65. to be... if two UUCP systems don't speak a common communications protocol,
  66. they can't exchange any data... in fact, they cannot even tell each other
  67. which files they want to send!
  68.  
  69. There are a number of different communication protocols available within
  70. the UUCP universe.  The 'g' protocol is by far the commonest, and it's
  71. the one you'll most often encounter.  uupc 3.0 also supports the 'f'
  72. protocol, and you may wish to use it under certain conditions.  Other
  73. implementations of UUCP support the 't', 'e', and 'x' protocols,
  74. which uupc 3.0 does not understand and cannot use.
  75.  
  76. The 'g' protocol
  77. ----------------
  78.  
  79. The 'g' protocol is an answer to the following question:
  80.  
  81.   "How can we transmit data, consisting of arbitrary 8-bit characters,
  82.    over a telecommunications link which is capable of sending 8-bit
  83.    data, but which is subject to noise and cannot be relied upon to
  84.    deliver all of the characters correctly?"
  85.  
  86. The 'g' protocol is most commonly used over normal dial-up modems.
  87. It can also be used with dedicated (leased-line) modems, or over
  88. direct machine-to-machine connections.
  89.  
  90. 'g' is a "packet-oriented" protocol. The data being transmitted is broken
  91. up into packets, or chunks, of an agreed-upon size. The sender transmits
  92. one or more packets, and then waits for the receiver to acknowledge that
  93. the packets have been received correctly. Packets are numbered (so the
  94. receiver can tell if they have arrived in the proper order, or if a packet
  95. has been lost in transit) and contain a checksum and a CRC code (so the
  96. receiver can determine if any of the contents have been corrupted by noise
  97. on the phone line). The receiver sends back a series of short packets, to
  98. ACKnowledge the successful reception of a packet, or to Negatively
  99. AcKnowedge a packet which has been lost or damaged. If the sender receives
  100. a NAK, it "backs up" and retransmits packets starting with the first one
  101. which was lost or damaged.
  102.  
  103. Most implementations of the 'g' protocol use a "sliding window".  The
  104. sender transmits a burst of packets... typically 3 of them... and
  105. then waits for the receiver to ACK packet #1.  Once packet #1 has been
  106. ACKed, the sender transmits packet #4 and waits for an ACK from packet
  107. #2, then sends #5 and waits for an ACK from #3, and so forth.  The
  108. sender will almost always have a "window" of one or more packets
  109. which have been sent, and not yet acknowledged.
  110.  
  111. The use of a multi-packet window improves the 'g' protocol's performance.
  112. If the window is only 1 packet wide, the sender must stop and wait
  113. for an ACK after each packet... and, because it will take the receiver
  114. some amount of time to check the packet's correctness and send back
  115. an ACK, the transmission will "stall" and the line will sit idle
  116. between packets..  If the window is two or more packets wide, then the sender
  117. can be transmitting a packet while the receiver is checking the
  118. previous one and sending back an ACK... and, with a bit of luck and
  119. a fair wind, the sender will always receive the ACKs in time to allow
  120. it to send another packet as soon as it's ready.
  121.  
  122. By default, almost all UUCP implementations use the 'g' protocol with
  123. a 3-packet window, unless instructed otherwise.  It gives good performance,
  124. and permits rapid recovery if a packet is damaged in transit.
  125.  
  126. Under some conditions, it may be useful to increase the size of the 'g'
  127. protocol's window.  This will increase the amount of unacknowledged data
  128. which can be "in transit" at any particular moment, and can reduce the
  129. impact of a "sluggish" receiving system (one which doesn't always
  130. acknowledge packets instantly) or of a telephone connection which delays
  131. transmissions significantly (for example, an overseas call via a
  132. geostationary satellite).
  133.  
  134. You should not assume that a larger 'g' window will always increase
  135. performance, though.  If your phone line is noisy, and packets are
  136. damaged in transmission at all frequently, then a larger window won't
  137. help much, and can actually hurt... most errors require the retransmission
  138. of an entire window's worth of data, and a larger window thus requires
  139. more retransmission.
  140.  
  141. Also... there are cases in which some UUCP implementations say that they
  142. can handle a larger window, but in fact cannot do so gracefully.  These
  143. implementations can "drop packets on the floor" if the packets arrive
  144. in large numbers at high speeds... this usually leads to protocol
  145. timeouts, retransmissions, and long delays.
  146.  
  147. You can also increase the size of the packets used by the 'g' protocol.
  148. In theory, the 'g' protocol can use packets of sizes from 32 to 4096
  149. bytes (the packet size is always a power of two).  In practice, most
  150. uucp implementations use a hard-coded packet size of 64 bytes.  Some
  151. can send packets of a few other sizes, if you ask them to;  very few can
  152. accept packets of any size other than 64 without becoming acutely ill.
  153.  
  154. Increasing the packet size can increase performance, because more data
  155. is transmitted per packet (each packet having a fixed amount of overhead)
  156. and because the total size of bytes in the window is increased.  It can
  157. hurt performance over noisy phone lines, because more data must be
  158. retransmitted after an error.  Furthermore, many uucp implementations
  159. behave very impolitely if one even attempts to negotiate a packet size of
  160. other than 64 bytes... some implementations send invalid packets, and some
  161. dump core or disconnect abruptly.
  162.  
  163. The 'f' protocol
  164. ----------------
  165.  
  166. The 'f' protocol is an answer to the following question:
  167.  
  168.   "How can we transmit data, consisting of arbitrary 8-bit characters,
  169.    over a telecommunications link which cannot send characters with
  170.    their 8th bit turned on, or send certain control characters... but
  171.    can be relied upon to deliver data reliably in almost all cases,
  172.    and can be trusted to perform flow control at all stages of the
  173.    link?
  174.  
  175. The 'f' protocol was originally developed to send data over X.25
  176. packet-switched networks (PSNs), via direct connections between
  177. a computer and a packet assembler/disassembler (PAD).  It has also
  178. shown itself to be useful when sending data over a dial-up phone
  179. connection between computers whose modems support either MNP (the
  180. Microcom Network Protocol) or V.42.
  181.  
  182. The 'f' protocol is a "streaming" protocol.  Data is transmitted as
  183. a sequence of bytes, without packet headers or trailers.  Data is
  184. sent continuously, except when the data link (modem or PAD) uses
  185. a flow-control mechanism to report that the link is becoming
  186. backlogged... at which point the transmission ceases until the
  187. link is once again free.  The only characters transmitted over
  188. the link are printable 7-bit ASCII characters... any other (high-bit
  189. or control) characters in the original data are converted into
  190. two-character "escape sequences" by the sender, and are converted
  191. back into their correct form by the receiver.
  192.  
  193. The receiver does not send back periodic ACK/NAK indications, as is done in
  194. the 'g' protocol. Instead, it calculates a checksum of the file, as the
  195. file is received. At the end of the file, the sender transmits the checksum
  196. that it has calculated, and the receiver checks this value against its own
  197. version. If the checksums match, the receiver says (in effect) "Got it!" If
  198. the checksums do not match, the receiver sends a "Beg pardon, how's that
  199. again?" and the sender retransmits the _entire_ file.
  200.  
  201. As you can infer, the 'f' protocol is extremely sensitive to data
  202. errors... a single one-byte error anywhere in the file will cause the
  203. entire file to be retransmitted.  For this reason, the 'f' protocol
  204. should _not_ be used over dial-up modem lines, unless the modems
  205. support MNP or V.42 error control and have been configured to use it.
  206. Similarly, the 'f' protocl should _not_ be used if you are running
  207. LocalTalk via your printer port... when LocalTalk packets arrive, the
  208. LocalTalk driver turns off interrupts for a few milliseconds, and this
  209. can cause your modem port to overrun its FIFO and lose a character or
  210. two.
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.